home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / lisp / elk-2_0.lha / elk-2.0 / MIGRATE < prev    next >
Text File  |  1992-11-08  |  2KB  |  48 lines
  1. This file lists changes in the interpreter kernel that affect the
  2. interface to extensions to Elk.
  3.  
  4. Changes in release 2.0:
  5.  
  6.      o  The Elk include file "scheme.h" now is in a different directory
  7.     (include), so you have to change the -I option in your Makefiles.
  8.  
  9.      o  <errno.h> is no longer included by "scheme.h", so you have
  10.     to include it in your extensions if it is required.
  11.  
  12.      o  lib/string.h is included automatically if you include scheme.h.
  13.  
  14.      o  It is no longer necessary to pre-link extensions against
  15.     lib/util/objects.o or lib/util/symbol.o.  The files now are in
  16.     a library (libutil.a); extensions are linked against this
  17.     library automatically when they are loaded into Elk.
  18.  
  19.      o  The way new Scheme objects are allocated has changed as a
  20.     side-effect of adding the necessary hooks for the generational
  21.     garbage collector (which is not yet present in Elk 2.0).
  22.     
  23.     The function Get_Bytes has been replaced by the new function
  24.     Alloc_Object.  Alloc_Object already returns a Scheme `Object';
  25.     there is no need to use SET any longer.  The arguments are the
  26.     object's size in bytes, the type, and a flag indicating whether
  27.     the object is constant (constant objects may be placed into a
  28.     read-only portion of the memory in later versions of Elk).
  29.  
  30.     So you have to replace old code to allocate an object of type
  31.     T_Foo that looked like this:
  32.  
  33.        Object o;  char *p;
  34.  
  35.        p = Get_Bytes (sizeof (struct S_Foo));
  36.        SET(o, T_Foo, (struct S_Foo *)p);
  37.  
  38.     by this:
  39.  
  40.         Object o = Alloc_Object (sizeof (struct S_Foo), T_Foo, 0);
  41.  
  42.     (use 1 instead of 0 if the new object is considered immutable).
  43.  
  44.      o  If you store weak pointers to objects and forward the pointers
  45.     explicitly in an after-GC function, you are now required to use
  46.     a set of new macros.  See src/terminate.c and lib/util/objects.c
  47.     for examples.
  48.